1,000+ Great Games

home *** CD-ROM | disk | FTP | other *** search

/ 1,000+ Great Games / 1_1000 Games.iso / DOSGAMES / REX210.ZIP / REX.DOC < prev next >

Wrap

Text File | 1995-02-02 | 132.7 KB | 2,428 lines

IMPERIUM REX v2.10 - DOCUMENTATION (February, 1995) --------------------------------------------------- Copyright (c) 1989-1995 Brainstorm Software 0. PRELIMINARIES Concept development, programming, and testing by Glenn Robins. Concept development, testing, and story writing by Jens Winslow. All documentation (this manual and on-line help) written by Glenn Robins. This is FREEWARE: You may freely distribute this program so long as it is distributed in its entirety and is unaltered. Please read LICENSE.TXT before continuing. If there are any questions or comments, please address them via e-mail to: ROBINS@QUCDNTRI.EE.QUEENSU.CA If your mail is returned as undeliverable, or if you have not received a response, please try AA606@FREENET.TORONTO.ON.CA If this game is interesting to you, it would be wise to register by sending a brief e-mail message to me. I may then be able to notify you if problems are found, or if a new version is released. There is nothing else involved with registration, and you are not obligated to pay or do anything! I am only encouraging registration so that I may have an idea of how many people are playing the game, so I know whether or not it is worth continuing with this project (to which I contributed 6 years of part-time effort so far). FYI, approximately 30 people are known thus far to have tried this game at one point or another, to my knowledge. I hope this is only because a select few decided to register. The following two FTP sites have accepted v1.01 for archiving: archive.umich.edu:/msdos/games/strategy/rex101.zip, ftp.funet.fi:/pub/msdos/games/strategy/rex101.zip. The following FTP site has accepted v2.00 for archiving: ftp.funet.fi:/pub/msdos/games/strategy/rex200.zip. For some reason, umich has not accepted the update. I will try them again for v2.10. I will also upload this game to: wuarchive.wustl.edu:/pub/msdos_uploads/games, as rex210.zip, but uploads to this site are purged after roughly 4-6 weeks I believe. You may also wish to FINGER me at robins@qucdntri.ee.queensu.ca in the event my plan file has anything interesting to say about the game, or anything else. I will also try to follow the COMP.SYS.IBM.PC.GAMES.STRATEGIC newsgroup (which I have failed to do lately), if anyone tries to contact me that way. I don't know how much longer I will have the QUCDNTRI account, but will try to forward my mail automatically when I obtain another one, or to the FREENET account. This game will cost you NOTHING to play, except time. Be warned that depending on the setup, it could take months until the state of the game reaches a point where someone, or everyone resigns. It is NOT a game that can be completed during a lunch hour (well, unless you don't know what you're doing). The rest of this manual has not changed from v2.00 to v2.10. TABLE OF CONTENTS 1. HARDWARE REQUIREMENTS 2. INSTALLATION - GETTING STARTED 3. GAME DESCRIPTION AND OBJECTIVES 3.1 STANDARD ORDER OF EVENTS 4. BUILDING AND PLAYING GAMES 4.1 BUILDING A GAME 4.2 TYPICAL START TO A GAME / PLAYING TIPS 4.3 REMOTE PLAY PROVISION AND PASSWORDS 5. USER INTERFACE CONVENTIONS 5.1 FILE SELECTION MODE 5.2 KEYBOARD INPUT MODE VS. MOUSE INPUT MODE 6. ON-LINE HELP 7. GENERAL INFORMATION ON OBJECTS 8. NAMING OBJECTS 9. OBJECT SPECIFICATION TABLE 10. DETAILED OBJECT DESCRIPTIONS 11. TRANSPORT TABLE 12. OBJECT SPECIAL-ATTRIBUTE TABLE 13. MAP DISPLAY DESCRIPTION 14. MAP FEATURE OBJECTS 15. GRAPHICAL WORLD MAP VIEWS 16. MOVE MODE 17. RAIL TRANSPORT (SCHEDULES AND MDT) 17.1 RT SCHEDULE (RTS) 17.2 MINIMUM DISTANCE TRACKING (MDT) ALGORITHM 18. GAME PARAMETER TABLE 19. PLAYER MESSAGES 20. TECHNICAL INFORMATION 20.1 WORLD MAP SAVE FORMAT 21. FUTURE POSSIBILITIES / CLOSING COMMENTS 1. HARDWARE REQUIREMENTS - Any 80x86 processor will do (there is no processor-specific optimization), although a 386 or above would be nice for faster reaction times for screen painting, on-line help retrieval, etc. - As inferred by the above, no math co-processor is required, nor would it be used anyway since no floating point arithmetic is done! - At least 500K of DOS RAM is required (maybe a little bit more). Upper memory is not accessed (i.e. no extended or expanded memory is required). - Sound cards are not supported - just the PC speaker is used. - VGA is required (just regular VGA with 512K of video memory - no fancy stuff). Most of the interface is based on an alternate- character-font text mode. 320x200x256 graphics mode is also used. - If you don't have a colour monitor by now, get one! (In other words, a colour display is mandatory). - The program should be installed on the hard drive for faster access. Space requirements are minimal for the program itself (around 1000K), but game files are around 232K each. - A MOUSE is STRONGLY recommended, although not required. If there are any problems with mouse cursor movement or anything else, it may be that your mouse driver is too old. I am using a Dyna-Mouse driver, version 9.06. Only the 2 buttons are used (for those of you with 3- button 'mice'). - I believe there is no restriction on the DOS version (assuming you have version 2 or above (!)). It is suggested that you do not run this program under Microsoft Windows, or any other multi-tasking OS. It will most likely work without significant problems, but you may find that sound delays are too long or short - each time you begin the editor or player, a delay- loop counter is set based on the system clock and is compared to a reference count acquired on my machine, which will account for machine speed differences; with a multi-tasking environment hooked onto the timer tick interrupt and doing funny things in the background, this could produce a misrepresentative delay-loop count. Perhaps there is a better way to produce sound, but I haven't looked into it much - it's not really important in this game anyway. However if the sound delays are not as they should be it could become irritating. In any case, the sound can be turned off in the game player. 2. INSTALLATION - GETTING STARTED The following are all the files that should be included in distribution: REX .EXE - Game player REX .HDX - On-line help index for game player REX .HLP - On-line help for game player REX .DOC - Off-line program documentation (what you're reading) REXEDIT .EXE - Game Manager/Editor REXEDIT .HDX - On-line help index for game editor REXEDIT .HLP - On-line help for game editor LICENSE .TXT - Software license agreement CITNAMES.REX - Neutral Player city names WINNING .REX - NP messages sent to players if doing well LOSING .REX - NP messages sent to players if losing CHARFONT.REX - Character font DATAFILE.EXE - Creates text file from data files (DATAFILE.TXT) AWORLD .MAP - Sample world map (by Jens Winslow) JUSTLAND.MAP - The above map without extra surface types SWORLD .MAP - Small sample world map (by Jens Winslow) IWORLD .MAP - Sample map with scattered islands (by Jens Winslow) RWORLD .MAP - Map suitable for 2-plr region game (by Glenn Robins) REVISION.TXT - Revision history OBJSPECS.REX - Object specifications data file GAMEPARM.REX - Game parameter data file IMPORT .EXE - Program to import v1.0 or v1.01 data files GAMEINFO.EXE - Provides summary information for a specified game PRACTICE. - Practice game (one-player) PRACTICE.TXT - Description of practice game MAPEDIT .EXE - Map editor MAPEDIT .VML - Graphics library MAPEDIT .BML - Graphics library MAPEDIT .FNT - Character font MAPEDIT .DOC - Program documentation for map editor The following additional file is created when you run the game editor: OPTIONS .REX - Game player sound option memory The first thing you should do when you obtain the distribution copy is to make sure that the above options file is NOT present - if it is present, this means you have acquired a used copy. Otherwise, run the Game Editor (REXEDIT) which will not only create this file needed to run the Game Player, but it will also perform an integrity check of all distribution files (except CITNAMES.REX, WINNING.REX, LOSING.REX, OBJSPECS.REX, GAMEPARM.REX). However, don't let these checks give you a false sense of security - it is always possible that someone hacked around with the files and redistributed them. Also note that CITNAMES.REX, WINNING.REX, and LOSING.REX are exceptions to the License Agreement LICENSE.TXT, as they are meant to be modified by the user at will. If the integrity check fails due to one or more corrupt files, the Game Editor will not run. Since the integrity check was performed because the options file was missing, the Game Player will not run either. You must obtain an original distribution copy in this case. Please remember that the sample maps are checked as well so make sure you do not make any changes to them (or if you do, save them under different names). It is recommended that you keep a copy of the original files somewhere else, in case one or more of the working copy files are accidentally altered. The Game Manager/Editor is used to create/edit world maps, to build new games, and to edit the object specification and game parameter tables. The Game Player is used solely to play a current game. The Map Editor program is an enhanced world map editor which can be used in place of the one built into the Game Editor. For more information, read the manual for this program - MAPEDIT.DOC. The Datafile program creates a formatted text file with information contained in the game parameter table and the object specification table. It is this text file, <DATAFILE.TXT>, that should be printed so that a hard-copy reference is available while playing the game. You will be asked for the particular data entry to extract to file from either or both of the data files. The Gameinfo program will provide some general information about the specified game file, such as a list of players, playing time, turn number, current player, etc. Note that the estimated playing time that is shown here and in the General Report of the Game Player will wrap around to 0 if it exceeds 255 hours and 59 minutes. I suppose that if you have been playing the game this long, you won't care anymore. If you add the command-line parameter '?' after any of the programs provided (REX, REXEDIT, GAMEINFO, DATAFILE, IMPORT, or MAPEDIT), it will present you with a list of command-line parameters that can be used. A parameter for REX and REXEDIT that should be mentioned here is '/m', which will tell you how much memory is left once the program is loaded. This indicates how close you are to not being able to run the program, which is of special consideration if you are planning on adding more TSR's or whatever. It is mandatory that you read and understand the Software License Agreement <LICENSE.TXT> before using this software. 3. GAME DESCRIPTION AND OBJECTIVES This is basically a world domination game: Your goal is to take over and rule all of civilization (for the good of the people). Strategy, tactics, and logistics all play a role in the success of your empire. You will start by ruling one city and having ownership of just a few objects. Then, you will seek out the establishments of your opponents and forcefully persuade them to follow your cause (since there is no time to reason with them). However, the largest and most powerful of your prey are an alliance that stands for freedom and independent rule, and resists change with all their might: the Neutral Player (NP). The actual introductory story is presented to you as you begin a new game - the one presented here is an extremely abbreviated version. There is a minimum of 1 and a maximum of 3 human players, and always one Neutral Player that is played by the computer. Playing with only one human is considered to be a practice game, as there is no threat by a human opponent, and more importantly, the introductory story will be inconsistent! It is a good idea to play a practice game for a while individually, to get a good feel for the game before engaging in a real contest. A player is officially out of the game when all objects are destroyed and all cities lost. It may be more often that a game is declared over when all but one player resigns. Player 1 is always WHITE in foreground colour (but not necessarily good); Player 2 is always BLACK (but not necessarily evil); Player 3 is always YELLOW (but not necessarily cowardly); and Player 4 (NP) is always RED (no comment). Colours cannot be chosen at will - players are activated in sequence from 1 to 3 (i.e. Player 3 can not be chosen for an individual in a two-player game). A key to your growth and development is the exploitation of resources. There are three types: Grain, Mineral, and Oil (see MAP FEATURE OBJECTS). Cities and Settlements may collect these resources each turn if they are scanned and in collection range. Cities can produce objects that constitute your offensive and defensive forces. However, to produce any object costs resources and MegaCredits (1 MC is a million credits, where a credit is the standard global currency). MegaCredits are obtained mostly from tax revenue (proportional to your total tech-level) and profit from transactions on the global market. There are three categories for the application of technology: Terra- Tech (non-aquatic terrain-based objects), Aero-Tech (objects in flight), and Hydro-Tech (aquatic-based objects). Moreover, there are five levels of technology for each category (1 is the most primitive, and 5 is the most advanced). Cities, over time, may advance tech- levels in each tech-type if sufficient funds are invested in the city's intellectual growth. There are different surface types which affect the performance of objects in different ways. These surfaces are: LAND, WATER, MOUNTAINS, SWAMP, and JUNGLE. There are also infrastructure types that may be built on some of these surfaces, which are: RAIL, ROAD, and CANAL. The global market is a virtual economy in which the exchange of resource units takes place. If transactions are made carefully, you may make a lot of money. It is also a secondary source for resources if your own pool is low in a particular resource type (if you have the money to spend). It is important that you read the entire manual before playing. Writing this manual has been an interesting exercise in collating information - whether or not it deserves a passing grade is up to you. It is however my best effort given time constraints. This manual and the on-line help are complementary - it is important that you also read the on-line help for every new situation while playing the game, and while exploring the game editor. It is the on- line help that is devoted to explaining game details and user input options as you play. The purpose of this off-line documentation is to provide an overview and to define all terms referred to in the game, as well as being a reference. 3.1 STANDARD ORDER OF EVENTS A couple of terms need to be defined: A ROUND is that which a player uses to give orders and move objects; A TURN is a collection of rounds - one round for each player. Rounds are not simultaneous events - they occur consecutively in game time for each player, in order of player number. The Neutral Player is always the last player to move in the turn. It is only in the very beginning that a player may be advantaged by this - during normal play, the advancement of turns is relatively transparent since rounds are continually cycled in the same order. For a human player, the normal sequence of events in a round is as follows: - Player messages are read - The global market status is examined (checked for change) - Objects that run out of fuel are destroyed or fueled up - Damage report is presented - Destruction of owned feature object(s) is made known - The age of enemy objects is incremented - Satellites are moved and scanned for - Resources are collected - City production is updated, repairs are made - Movement points are set for objects - Cities may attack in-range enemy objects - <Player activity> - Market transactions are performed at end of round I hope this gives an appreciation of the complexity of this game! 4. BUILDING AND PLAYING GAMES 4.1 BUILDING A GAME Before a game can be built, a world map must be chosen. There are some sample maps provided, each having a different arrangement that depends on the type of game you want to play, and the number of players. It may take some fun out of playing if you already know the layout of the world, but so far no decent random map generation algorithm has been found or developed. In any case, it will probably take a few games before you have the maps memorized. If you are unhappy with the provided maps, you can create your own using MAPEDIT, or by using the editor provided with REXEDIT. Once you know which map you will use, run REXEDIT and then LOAD the particular world map into memory (via map editor functions). If you have been playing around in here before, and the map in memory has been used, then clear it first. That is because LOADing a map into memory will not clear everything such as object positions (if a game has been loaded previously). Once the map is loaded, you will have to decide which set of game parameters and object specifications to use for this particular game. You may want to browse the data tables, especially the game parameter tables which contain parameters used during the process of building a game such as number of cities to place, scattering factors, number of resources to place, etc. You will find that the number of island, coastal, and inland cities will depend on the type of world map you are planning on using. Choose the build game option from the main menu, where you are asked to enter the names of the players. From now on, always check the on-line help for every new option you are asked to select - especially for the pooled resources and regions options. If you chose a non-region game, you will be asked for the filename. If you cancel at this point, the game built will be lost and you must start over. If you chose a region game, you will be thrown into the editor where you will have to save it on your own. 4.2 TYPICAL START TO A GAME / PLAYING TIPS If you play a normal non-region game (you'll know what that is when you read the on-line help when building a game), you will automatically be given a Fuel Depot, and a Hover-Scout. These are the two most important and useful objects that you can have as you start, since you are now able to locate resource deposits. It is possible that more resources might surround your HQ (other than the four that are deliberately placed there) since the immediate area has not been scanned by a Hover-Scout. Scouting your immediate surroundings is also a good idea, to make sure there isn't a city just outside your city scan range (or some other nasty surprise). Knowing the surrounding terrain early in the game will enable you to quickly determine your strengths and vulnerabilities with respect to your own location, and such knowledge may dictate what type of objects you should focus your production on. Make sure that your scout moves along the map diagonally, forming a triangular or diamond-shaped search pattern - this is the most fuel-efficient scheme for patrolling the maximum area. If you happen to find a Neutral city near you, concentrate on a quick but dedicated effort to take it. The longer you wait taking a city, the more difficult it will be to take it, and the more potential production time will be lost. Do not send an object on a lost cause - they are very valuable in the beginning. If you intend on taking a city, make sure it is taken in one combined assault - attacking in bits and pieces will cost you more time and resources than it will cost the city to repair itself. You will discover the proper balance with experience, as with all causes. Make sure that before you attack, you click on the city in TACTICAL when its age stat is 0 to know what the tech- levels are for that city (immediately after scanning it). This way, you will know what kind of objects it can produce, and the maximum number of guards it can sustain which determines its damage potential, and maximum hit points. It is also a good idea to produce guards early on - it is something that can be easily forgotten until it's too late. Try to take coastal cities so that you can build destroyers or submarines. This will give you an edge for defense and offense. Keep in mind that the computer will build these too, so you need to be ready for them anyway. Concentrate on a strong defense once you take a city - make one or two photon cannons and build up the guards (very important). When you take a city, you may expect things thrown at you continually so you need the defense. The spreading and quantity of the cities affects the game considerably. If there are many cities close by, you can expect a continual (or even continuous) onslaught. To alleviate this, you may want to ensure the cities are sufficiently spread apart (base this on fuel range of objects the NP can produce); you can also change the max. age of an NP city to something a bit lower, so that they start out less developed (lower tech-levels). Try making a lot of gun boats and armies - they are hard to hit and having the quantity will distract the NP and give it more things to shoot at, prolonging the battle so you may move in or produce reinforcements; it's surprising how effective a large force of not-so-powerful objects can be. You may even choose to sacrifice some hover-scouts, which can make all the difference. It may sound like you need to produce a lot of objects which will cost more resources than you have; it really depends on how lucky your setup is in terms of resource allocation. It is advisable that you play a couple of games with POOLED RESOURCES first, which will solve many of your infrastructure problems. Pooled resources will allow any of your cities to have instantaneous and unlimited access to all resources in your HQ, so there is no need to transport resources. This is also VERY convenient for when you take a new city that isn't self-sufficient (being able to collect one or more of each and every resource type). It will otherwise take a long time to establish a proper defense by way of production, if you first have to ship resources to the city. If you are not playing pooled resources, you should plan on shipping the required resources to the city you are about to take, possibly having them already loaded onto a transport and waiting outside the battle zone around the city. This brings up another important point: you really ought to resource-scout the collection area of a city you are hoping to take. Knowing the resources it will collect when and if you take it, is vital information - it may even lead to a decision of not wanting the city. If you discover it is self-sufficient, you will want to invest all you can to take it. You may question the tactics of flying a hover-scout all around an enemy city - the point is to do it carefully without being spotted or shot at, which may require fuel and patience, both of which you may find lacking! Aero-porters loaded with photon cannons are handy - fly near a city and unload one or two of them just outside the city's attack range (the guard's AR) and cover them with a couple of aero- fighters (or even a destroyer if possible). I know it takes time to produce these, but there's no real hurry to go out and pound the NP - as long as you can keep up your defenses, you should be OK. You'll never be able to charge and take all the cities before the NP can make a Battle Cruiser, so stop trying (if you are, that is). By the way, make sure you produce at least one submarine and keep it handy in case of an encounter with a battle cruiser. The NP isn't smart enough to escort a battle cruiser with a destroyer or submarine, unless it happens by coincidence, so you're submarine can pound on it without being spotted until it decides to go home for repairs. A human player, however, may not be so careless as to let its battle cruiser sail away without such protection. 4.3 REMOTE PLAY PROVISION AND PASSWORDS The remote play provision is a feature that allows you to save and quit the game in-between player rounds, so that the game file may be transferred to another location and played at a later time. If the game file is transferred by modem or by e-mail, it may be wise to compress the file first, using your favorite compression program. Playing by e-mail will most likely require a UUEncoder and UUDecoder so that the file may be sent as ascii text, unless your mailer allows you to attach binary files. This remote play provision mode may be turned on or off in the Game Options window during a player's turn. It is a good idea at the beginning of a game to get together with all the players and spend a day playing on the same computer (with this mode off of course) so that the length of the turns will become longer for when you play remotely. By the way, the Neutral Player will do its turn immediately after the last human player in the turn ends his/her round, and the game will save and quit when the NP finishes. There is no reason to be concerned with regard to playing the same game on different computers with their own installations of Imperium Rex - all the necessary information for purposes of consistency are stored in the one game file. Having different sets of specifications stored to OBJSPECS.REX or GAMEPARM.REX will have no effect as all this information has been copied to the game file for independent access during the game building process; and having different NP message files (WINNING.REX, LOSING.REX) only implies that the randomly chosen messages that the NP sends people may be different. Changing the game sound option is a local effect, and is not stored with the game file. The passwords feature may only be turned on or off in the Game Editor (in the main edit menu after selecting the game to edit). When turned on, it will ask each player for a password which is necessary to type each time that player's round begins. It is also required that all players type their passwords before anyone is able to edit the game. Passwords may be changed from within the Game Options window during a player's round. The passwords option may of course only be turned off when editing the game, which requires everyone's passwords - it is therefore very important that no one forgets their password. It is also important that any player who resigns the game either surrender his or her password to everyone else, or at least clear it by changing it to nothing (just hit ENTER for a password); otherwise, the remaining people in the game will not be able to turn the passwords off if they need to (or edit something). These passwords are of course stored in the game file in an encrypted form. 5. USER INTERFACE CONVENTIONS This section describes all the user input terms used in all the documentation (including on-line help), and some general tips on getting used to the input interface. "<LB>", "CLICK [ON]", "SELECT": These terms refer to the LEFT MOUSE BUTTON, if using a mouse, or the following keys if in keyboard mode: ENTER/RETURN, INSERT/INS. "<RB>", "CANCEL": These terms refer to the RIGHT MOUSE BUTTON, if using a mouse, or the following keys if in keyboard mode: ESCAPE/ESC, DELETE/DEL. For all item selection input modes, where a list of items is presented and a status and button line appears at the bottom of the list, the following inputs are accepted: KEYBOARD: UP and DOWN ARROW keys - to move the selection bar through the list one item at a time, PGUP and PGDN keys - to move the selection bar up or down the list a page at a time, ENTER/RETURN - to select the highlighted item, or ESCAPE/ESC - to leave the list (cancel). MOUSE: Clicking on one of... The arrow pointing left (second button from left) is the UP key, The arrow pointing right (third button from left) is the DOWN key, The larger arrow '<' pointing left (first button) is the PGUP key, The larger arrow '>' pointing right (last button) is the PGDN key, or Clicking on an item in the list (doesn't have to be highlighted) will select that item, or Clicking <RB> (CANCEL) will leave the list. For menu items, which may be vertically or horizontally arranged, the following inputs are accepted: KEYBOARD: UP or LEFT arrow keys - to move the menu bar up or left, DOWN or RIGHT arrow keys - to move the menu bar down or right, TAB key - to cyclically move the menu bar down or right, ENTER/RETURN or INSERT/INS keys - to select the menu item, or ESCAPE/ESC or DELETE/DEL - to cancel or leave. MOUSE: Click on a menu item to select it, or CANCEL (right button). All other input modes are directly sensitive to where you click on the screen. It is a good idea to use the on-line help to be familiar with all input options for each input context. Generally, CANCEL will move up a level of input or abort an operation. Also, if in MOUSE input mode, keyboard commands will normally not respond in these other input modes (which are non-item-selection-oriented). 5.1 FILE SELECTION MODE A special mention of file selection is warranted here, although it wasn't supposed to be complicated, but could be if not careful. The same file selection window/user-interface is used for all file operations. The current, default directory appears on the top line; an input box appears on the left-hand side of the window; and a list interface appears on the right. The list interface is always the first to be active whenever the window is opened - this means that all input commands are intercepted by the file selection interface. Therefore, you may not just click on the input box on the left to enter in a filename manually. To do this, you must use CANCEL to exit the list interface and bring you to the manual input box. Once you are in this manual input box, you cannot directly move back to the list interface - to do this, you will have to CANCEL, which will bring you to the options on the bottom where you can CANCEL again (in which case you will need to re-select the option that brought you here), or select OK (in which case it is most probable that an error will occur which upon acknowledgement will bring you back to the list interface). Read the on-line help when you get to this window! It may take some playing around before you get completely used to it. It wasn't meant to be this difficult - it is really a programming problem where multiple input-types wasn't really anticipated for. Sorry! Another thing to mention is that directory/drive selection has been omitted to discourage file access and storage in places other than the program directory, and for simplicity. There is a requirement that the program directory be current at all times during program execution, so that the necessary files can be accessed transparently. However, you may still provide a full pathname for loading and saving files in the input box. 5.2 KEYBOARD INPUT MODE VS. MOUSE INPUT MODE If KEYBOARD input mode is enabled using the command line switch '/k', all MOUSE controls are disabled. This should only be used if you do not have a mouse, and/or the auto-detection of the presence of a mouse driver is incorrect, or if for some reason calling the mouse driver will interfere with something else. It is strongly recommended however to use MOUSE input mode whenever possible. One particular instance where '/k' must be used is if you are running either the game editor or player in a DOS Window (under Windows). As mentioned previously, it is also strongly recommended that you do not run this program under Windows. In KEYBOARD MODE, special keys have been designated to emulate the mouse. Whenever you are in an input mode that is sensitive to clicking at a particular screen location (other than option- selection-oriented input modes), the following keys will be checked: UP, DOWN, LEFT, RIGHT ARROW keys: Moves the 'mouse' cursor around the screen. INSERT/INS or ENTER/RETURN: Same function as LEFT MOUSE BUTTON (Select). DELETE/DEL or ESCAPE/ESC: Same function as RIGHT MOUSE BUTTON (Cancel). In MOVE MODE (only in KEYBOARD MODE) when asking for movement orders, the special purpose buttons in the status/control box can be selected by pressing the corresponding letter on the keyboard, such as 'S' for STANDBY. Although this may be a convenient feature, it is not available in MOUSE mode (sorry!). 6. ON-LINE HELP This help feature is context-sensitive. It can be invoked at any time by clicking the '?' button at the extreme bottom-right corner. This will open a window and present a brief description pertinent to the particular context that you are in. There is always only one page presented for any context. To acknowledge the help (leave the window), you can click anywhere or cancel anywhere except directly on the '?' button (an exception is placed in the code to prevent recursive calls to the help procedure). If in MOUSE mode, you may not use the keyboard controls to exit help. If in KEYBOARD input mode, on-line help is not accessible in all option-selection-oriented input contexts (due to the fact that the mouse cursor is not maneuverable under these conditions to select the '?' button). If there is no help for a particular context, the help based on the higher-level context is presented. This should not happen often - except for cases where the context is so obvious that no extra help is warranted, or for other cases where I just missed out on entering a help description for. If you happen to find a context for which no help is available and believe that some more information would be helpful, please let me know. 7. GENERAL INFORMATION ON OBJECTS An object is any independent entity that can move or be moved so as to appear on the map (including cities and settlements, which strictly speaking do not fall under this criteria). All objects are owned by a particular player. There is a hard-coded maximum of 300 objects that can be owned by any one player. It is impossible to exceed this boundary, unless there is a bug in the code. From time to time, you should check how many objects you own by reading the General Status Report, Page 1. If you have at least 280 objects, an option in the Orders menu is available to Disband an object. You are not allowed to disband cities or non-empty transports, or objects that are inside cities or are loaded. You are not permitted to create any new objects if the resulting total will be at least 290 - this includes resource containers! (This gives a safety margin of 10 in the event that there may be a bug). If, for whatever reason, you end up with more than 300 objects (or have an object with object number 300), save your game right away under a different name, and let me know! Otherwise, the results could be catastrophic. (Honestly though, it shouldn't happen - but who knows?) Keep in mind that this restriction also applies to the Neutral Player, and that all its cities are included in the object count. The following are the types of orders that can be given to an object: MOVING/MOVE TO LOCATION (x,y) This is an order to move to a specific location (given in MOVE MODE). This order cannot be given if the selected location to move to is outside the object's fuel range. STANDBY Do not ask for orders any more. The object will do nothing except scan once a turn. For objects that can crash if they run out of fuel over water, this order is cleared if the amount of fuel is 5 or less units, to warn you of the potentially life-threatening situation. WAIT Do not ask for orders this turn only. It will ask again next turn. FOLLOW By clicking on one of your own objects in MOVE MODE, the object will follow the selected object. If the selected object is a city, settlement, or transport, it will attempt to move inside once it arrives. This order is sometimes referred to as GOING HOME (for cities and settlements). LOADED This means that the object is loaded onto a transport. In all cases except LOADED, if the object scans an enemy, its orders are cleared. Cleared orders, or NO ORDERS, means that it awaits orders, and will probably ask you for orders in MOVE MODE if it still has movement points. If you leave an object in this state, it will still scan once a turn. 8. NAMING OBJECTS All of your objects can be given a name, which may have up to 19 printable characters. A name may be entered for an object in two ways. One way is in MOVE MODE, where clicking in the name field (second line on the left) for an object that is asking for movement orders will edit its name; names cannot be edited in this way for all other objects, such as cities and settlements. Another way is in TACTICAL MODE, where clicking in the name field before selecting an object will enter NAMING MODE. This is a TACTICAL "SUB-MODE" where by selecting a location where one or more objects reside will cycle through each object there and ask if you want to change its name. You know you are in NAMING MODE when "Select Object..." appears in the name field in TACTICAL. To exit this mode, click in the name field to return to TACTICAL; or CANCEL to exit TACTICAL MODE entirely. Neutral cities are named automatically as they are placed on the map. These names are taken from the file <CITNAMES.REX>, in sequence from the first one in the file, down to however many are needed. If you wish to add your own names, insert them at the top of the file using any text editor and they will be chosen first as cities are placed. When inserting your own names, make sure they are not longer than 19 characters long (or if they are longer, they will be truncated anyway). Make sure there are no blank lines in the file. If there are not enough names in the file for all the cities to be placed, the remaining cities will have blank names. 9. OBJECT SPECIFICATION TABLE This table is displayed in the game editor. All object specifications are stored in a file (OBJSPECS.REX) which is common to all games that are played. If this file is missing for some reason, the game editor will create a new one with default settings once invoked. Although specifications can be changed if desired, it is not recommended to change too many of them at any one time. It took years of playing experience (as the game was developed) to decide on a set of reasonably optimum parameters such that there is a proper balance. A balance in power of objects is essential for fair playing, and to the effectiveness of all objects in the table. If you change some specifications but wish to restore the original values, rename or delete the current OBJSPECS.REX file and run the game editor. To edit this table, just click on the number to change; or click on the surface type to toggle "survivability"; or click on a tech-type to change it. Listed below are the specifications and their meaning. HI This is the number of HIt points the object has if fully repaired. If this number drops to 0 for whatever reason, the object is destroyed. During attack, one damage point inflicted is one hit point lost. DP This is the Damage Potential of an object. If attacking, this is the number of times the object may fire on the enemy. If you are lucky, you may hit every time thus delivering a maximum of 'DP' points of damage. FR This is the Fuel Range of an object. If fully fueled, you may travel a maximum distance of FR units. It always costs one fuel unit to move from any location (except for some non-movement- associated objects). This value can have an alternate meaning in some instances which are explained in the object descriptions section. PT This is the Production Time in turns required to make an object in a city. WT This is the WeighT of an object (in weight units) if it is transportable, or the carrying capacity (in weight units) if it is a transport. It may also have other meanings in some instances which are explained in the object descriptions section. G, M, O These are the Grain, Mineral, and Oil resource units required to build the object. MC (The symbol that looks like an M inside a C) This is the amount of MegaCredits it costs to build the object. The following specifications are dependent on the surface type where the object resides. PBH This is the Probability of Being Hit by another object that is firing at you. POH This is the Probability Of Hitting an enemy object if firing at it. AR This is the Attack Range of the object in distance units. An AR of 1 will allow the object to only attack another object that is immediately adjacent. SP This is (indirectly) the SPeed of the object. It has special meaning for the LAND surface type. SP (LAND) is the number of movement points (MPs) assigned to an object at the beginning of the turn. All other SP entries are the number of MPs it costs to move FROM the corresponding surface. It always costs 1 MP to move from LAND. There are some exceptions to these rules for RAIL and ROAD. Road is treated as LAND only for movement (it will only cost 1 MP for any object to move from road, without regard to surface type). The exceptions for rail pertain to the Rail Transport (RT) and the Rail Constructor. Objects of speed 0 are termed "non-movement-associated" which means they cannot move on their own accord - their movement is restricted so they can only be unloaded, loaded, moved into a city/settlement directly adjacent, or moved out of a city/settlement to a directly adjacent empty surface. They are not capable of moving from its own location (outside) to another empty surface. SR This is the Scan Range of the object in distance units. Enemy objects that move within your SR, or are in your SR when you move, will have a chance of being scanned. If an object is scanned, its AGE STAT will be set to 0 (displayed beside the enemy object) - this is explained in the section on object stats (map view). POS This is the Probability Of Scanning an enemy object. If a scanning check is done due to movement, this is a factor in deciding if you scan the enemy. PBS This is the Probability of Being Scanned by an enemy object. If a scanning check is done due to movement, this is a factor in deciding if the enemy scans you. For each firing attempt, the probability of an object being hit is the product of POH of the attacking object and PBH of the object being attacked (well, actually, it's POH*PBH/100). The same applies to POS and PBS with respect to scanning. A scan takes place after each movement of one distance unit for all objects to check if you see an enemy, and to check if an enemy sees you. (A standard uniform random number generator is used). If a surface type for an object is highlighted in blue, then the object may move to this surface. The tech-type of the object is the one highlighted in blue. The tech- level of the object is underneath the tech-types, and may range from 1 to 5 (from primitive to the most advanced). Of course, the symbol to the left of the object name is the standard tactical symbol for that object. 10. DETAILED OBJECT DESCRIPTIONS (There is no logical order to the following list, except for the most part being in the order of conception.) ARMY UNIT An army is a group of soldiers, with light artillery. Producing an army involves standard training of militia or civilians (whoever is "available") that are present in the city. Population in cities or the morale of the people is not an issue in this game. There are no special exceptions in the specification table. CITY This is an establishment that is reasonably permanent, used to sustain your population, and produce and repair objects. A city can be taken over by an enemy but such an act will bring the city down to tech- level 1 for all tech-types. There is no restriction on the number of times a city can change owners. A city may only be destroyed by a CITY DEVASTATOR. Objects are repaired by a city whenever they are left inside at the end of the turn; they are put into STANDBY at this time and orders are cleared when repairs are complete. The number of objects repaired each turn is not restricted - they all gain one hit point per turn. Repairs may be ceased and the object used at any time by clearing its orders and moving it outside the city. Resources that are within a radius of 3 units will be collected by the city at the beginning of your round, so long as they have been scanned (are actually visible on your map). There is a collection and processing fee of 1 MC per unit of resources. There is no way to prevent collection and thus prevent the payment of these funds once resources are scanned in the vicinity - if you run out of MCs, resource collection will then halt. It is expected of the leader of the city to provide employment to the people if such work is available. They will not allow you to prevent the exploitation of resources if they are indeed accessible. Of course, they will not work for free if you happen to run out of MCs! If a resource deposit is in collection range of more than one city/settlement, it will be collected only by the city/settlement that has the lowest object number. There is no limit to the number of objects that can exist inside the city, but if the city were to be taken over, all of your objects inside will be instantly destroyed. Objects inside cities cannot attack, or participate in the city's defense in any way. Cities are able to spot submarines and satellites (within scan range of course). If at the beginning of your round, a city has spotted one or more enemy objects within attack range of your guard(s), you will be alerted and will be given the opportunity to attack them (see GUARD). The maximum number of guards sustainable in a city is HI + (guards per TL * (highest TL of city-1)). The following specs are redundant: DP, FR, PT, WT, G, M, O, MC, PBH, POH, AR, SP. SETTLEMENT This is a colonization of a small area, primarily for the purposes of collecting and processing resources. They are volunteers who seek profit from the exploitation of any surrounding resources (in a radius of 3 units). However, an agreement is established before-hand, that if you choose to suspend their operation, you will still accommodate the needs of the colony for survival. In return for your services and the generous payments you make for the collection of resources, they have agreed to provide shelter to those objects that happen to move into their settlement. However, if their settlement is destroyed, they will not accept liability for the destruction of the (cowardly) objects that chose to take cover instead of moving outside to defend them. If a resource deposit is in collection range of more than one city/settlement, it will be collected only by the city/settlement that has the lowest object number. Settlements have no intrinsic offensive capability - they are easily destroyed without protection! However, if a repair unit is left inside at the end of the turn, it will repair one unit of damage (one hit point will be restored). If more than one repair unit is left inside, only one will perform repairs. There is no way to prevent damage being repaired, unless you deliberately move all repair units outside. They are built by SETTLER UNITS, and cannot be moved. There is no way to destroy your own settlement (unless you politely ask your opponent to do so). A HYDRO-SETTLER UNIT will build a settlement on water, which can be thought of as an artificial platform (such as an oil rig is in our world). This can actually form a bridge between two adjacent terrain surfaces, although any objects that wish to pass over this "bridge" must enter the settlement first, which will usually result in the loss of some movement points. Settlements cannot be built directly adjacent to another settlement or a city (in case you thought of it, if this restriction was not in place, you could build ships in a city that is not beside water and build this "artificial and protected channel" to transport your ship to the water - this is what we have canals for). DP, POH, AR, and SP must be set to 0. FR, PT, WT, G, M, O, and MC are redundant. PHOTON CANNON This is a non-movement-associated offensive/defensive object. It can move onto transports or into cities or settlements that are adjacent, but cannot move on its own accord. FR and SP must be set to 0. CITY (HQ) In addition to being a city, this is your designated headquarters. All global market transactions are associated with the resource pool in your HQ. If your HQ is taken over, you must select a new one from your group of cities. If you have no other cities and you lose your HQ, the first city you take over will be your HQ. GUNSHIP This is a heavily armed attack helicopter. There are no special exceptions in the specification table. ANTI-SAT BUILDER This is a construction unit that can move on its own accord to a location where you wish to build ANTI-SAT DEFENSE. It is permitted to build ANTI-SAT DEFENSE inside a city or settlement. It was conceived to have no offensive capability, so DP, POH, and AR should be set to 0. WT is redundant. MINE LAYER This is a small mine laying unit that is designed to move on any surface and lay its mine. Once a mine is laid, the mine layer is dismantled. It was conceived to have no offensive capability, so DP, POH, and AR should be set to 0. SETTLER UNIT This is a settlement construction unit that can move on its own accord to a location where you wish to build a SETTLEMENT. It was conceived to have limited offensive capability (namely, lots of men with tools). There are no special exceptions in the specification table. BATTLE CRUISER This is a very big, ugly, and offensive boat, as the name implies. It was conceived to be the most powerful object of any tech-type. The attack range (AR) was deliberately set to be longer than the scan range (SR), due to the very large and powerful gunnery that can "transport" a shell over a very large distance. Beware that battle cruisers CANNOT detect submarines - this can prove to be very dangerous (you may want to consider an escort, such as a destroyer or submarine). There are no special exceptions in the specification table. AERO-PORTER This is a reasonably large cargo aircraft. See the transport table for a list of objects that it can carry. WT in this case is the total number of weight units that this transport can carry (it is not the weight of the transport itself). AERO-FIGHTER This is a very agile scout/fighter aircraft. They are valuable for instances where a quick and responsive attack is required, as they can travel large distances in a short time. Typical preys would be bombers, aero-porters, fuel depots, and other objects that have poor defensive capability. There are no special exceptions in the specification table. HOVER-SCOUT This is a very useful scouting object, and the only object that can detect resource deposits. If you do not have one of these objects for any reason, be sure to produce one right away. They are your key to resource exploitation and thus the expansion of your empire. They are also useful for destroying rail or road, or fuel depots. They can also set off mines (to use as an inexpensive mine sweeper, even if they might get killed). As the hover-scout moves, it automatically scans the surrounding area (within its scan range - SR) for resource deposits. If a location has been successfully scanned, it will show as highlighted when a resource- scanned area observation map is displayed. The game parameter table has an entry that specifies the probability that the hover-scout will detect a resource deposit. If it failed to scan, the location in question will not be highlighted. In MOVE MODE, there is an H button that if pressed, will display the resource-scanned area. This is an option that you should use often as you move your scout, to be sure that all area in its scan range has successfully been scanned. There are no special exceptions in the specification table. ANTI-SAT DEFENSE This is an establishment that continually scans the skies for an enemy satellite (at the beginning of your turn). SR is the range that this object can scan for a satellite, and AR is the attack range. If a satellite lies in-between AR and SR, you will be notified of the intruding satellite's presence, but cannot attack it. If the satellite is within AR, it will be destroyed on your order. Destruction of a satellite costs one missile, and the defense is dismantled when the last of its missiles has been fired. It has no defensive capability. DP must be set to 1; FR is the number of missiles this defense is given once built; AR and SR need only be set for LAND. PT, WT, G, M, O, MC, POH are redundant. Surface selection is also redundant (it may be wherever the builder can go). DETECTOR PLACER This is a mobile unit that can plant detectors on any surface type. It has no defensive capability - DP should be set to 0. WT is the number of detectors it is given once produced. This object is dismantled when it has placed its last detector. POH and AR should be set to 0. As it is an object with a very narrow purpose, it has been given no scanning capability, so SR was set to 0 (although it could be changed). If SR is 0, POS is redundant. LASER TANK This is a very sturdy and heavily armoured vehicle with a reasonably powerful cannon. It is a standard land-based attack unit. There are no special exceptions in the specification table. SPY SATELLITE Satellites are useful for quickly mapping out the world. An advantageous side effect is that it can also give you a good idea where your enemy is, as it has the capability of distinguishing the ownership of objects below it. Satellites of any ownership cannot collide into each other. They are equipped with maneuvering fuel, specified by FR. Each time the orbit is changed, one fuel unit is lost. If there is no fuel left, the orbit of the satellite can no longer be changed (unless you deliberately destroy it). They can move in a direction based on 45 degrees ("horizontally", "vertically", or "diagonally" across the map). They may also be placed in a synchronous orbit in which they continuously scan the same area. Normally, the world is non-wrapping to objects. However, satellites DO wrap from one side to the other. Once produced, a satellite may be launched in TACTICAL MODE only, by clicking on the city that produced it and finding its object window, where the launch button may be pressed. Grounded satellites (ones that haven't been launched yet) will appear in the Satellite Report (under the REPORTS menu). They are detectable by cities and anti-sat defense only. Satellites can see submarines. It may be helpful to be aware that the Neutral Player will not produce satellites. AR should be 0; HI, DP, PBH, POH, PBS are redundant. SP (LAND) is the distance moved at the beginning of each turn. Surface selection is redundant. TERRA-PORTER This is essentially a convoy of transport trucks. See the transport table for a list of objects that it can carry. WT in this case is the total number of weight units that this transport can carry (it is not the weight of the transport itself). HYDRO-PORTER This is a reasonably large transport ship. See the transport table for a list of objects that it can carry. WT in this case is the total number of weight units that this transport can carry (it is not the weight of the transport itself). ROAD CONSTRUCTOR This is a construction unit that places road segments. It has limited defensive capability. This unit has an auto-placement (A-P) mode where a segment is placed automatically each time the object is moved to a new location with no feature object already present. Placement will only occur at the location it is moved TO when this mode is on. There is also a manual placement command that can be used to place a segment at its current location, without using up its movement points. WT is the number of road segments that is given to the object once produced. It is dismantled when the last of its road segments is placed. GUARD A guard is an abstract object - it exists inside its city and cannot be moved. Guards are used to defend their city against enemy attack. They absorb hits when the city is attacked, and they can deliver damage to an enemy object in their attack range (AR). Each guard has its own hit points - when they are all lost, the guard unit is killed. If all guards are lost, the city is handed over to the attacker. If a guard unit is being produced when an existing guard has lost points, that guard will have an added hit point per turn. If the number of hits points exceeds the maximum for the guard, a new guard is produced. A simpler way to calculate the number of guards in a city is: guards = (total hit points of city / max. hit points per guard) + 1. If you have reached the maximum number of guards that can be sustained in a city, but do not have maximum hit points, there is no way to bring the city to maximum hits (the injured guards are there to stay until the bitter end). WT, FR, SR, SP, POS, and PBS are redundant. FUEL DEPOT Fuel depots can exist inside cities or settlements, or be carried on transports, or can be partly concealed outside, on any surface. They are the only means for fueling up objects. An object can fuel itself to maximum by moving to it if the depot is outside, or by moving into a city with fuel. If a transport is carrying a depot and runs out of fuel, it will fuel up from this depot. Objects moving onto a transport that has a fuel depot will fuel up automatically; however, if an object wants to fuel up from a depot inside a transport, but is not a compatible load, the depot must be moved off the transport first, and then have the object move to it. If there are more than one fuel depots at the same location (either in a city or settlement or in a transport) and an object will choose to fuel up, it will take fuel from the most empty depot first. Depots that are completely emptied will be dismantled at the end of your turn. Any object that fuels up from a depot will lose all its remaining movement points for that turn. You may transfer fuel from one depot to another by giving the receiving depot orders to fuel up (from the other depot) - this may save room on a transport if two containers are only half full for example. One fuel unit will be lost from the depot if moved outside a city or transport. However, no fuel is lost when loading onto a transport or into a city. If objects that require fuel are produced in a city with no fuel, they will be stranded until a depot is moved in, or until a depot is produced in that city. Once a fuel depot exists by either method inside the city, all objects with zero fuel (only) will automatically fuel up at the beginning of the round. Therefore, objects cannot fuel up the same round that the depot was produced, unless the depot is moved outside the city and then each object that is empty is manually ordered to fuel up from that depot. This alternative is not beneficial though, since it still takes a turn to manually fuel up. Fuel depots have no defensive capability, but have limited scanning capability. DP, AR, POH, and SP must be set to 0. FR is the amount of fuel given to a depot once produced. STEALTH BOMBER This is a long-range bomber. It is sometimes referred to as a transport, as it has a similar window interface and loading/unloading mechanisms. However, the only object type that can be carried is a bomb. Bombs are dropped to an immediately surrounding area using the bomb button in MOVE MODE. Bombs can be dropped on an enemy object, or on a rail or road (owned by anyone). If an object is destroyed by a bomb, and rail, road, or canal is at the same location, it is destroyed as well. A bomb dropped directly on a rail or road segment will guarantee its destruction, whereas dropping a bomb on a canal will destroy it with probability as given in the Game Parameter Table. It costs one movement point (MP) to drop a bomb. A bomber can carry a total weight determined by WT. If each bomb weighs 1 unit, then WT is the number of bombs that can be carried. RESOURCE CONTAINER These are only available in non-pooled resources mode of play. They are created by packing resources in cities or settlements. There is a hard-coded limit of 5 resource units per container. The weight of a container is specified by WT and is set by default to 5 (one weight unit per resource unit). An empty container cannot be created. Containers are the only means of transferring resources from one location to another, other than by using an RTS (Rail Transport Schedule). They may only be unpacked in a city or settlement that has room in its resource pool for the resources in the container. Unpacking a container automatically dismantles it as well. They may contain a mixture of resource types. Containers are independent objects that can exist outside cities, but are extremely vulnerable to attack. They are not capable of moving on their own accord, or attacking (it's literally just a container). DP, AR, SP must be set to 0; SR should be set to 0; FR, PT, G, M, O, MC, POH, and POS are redundant. DESTROYER This is a well-armoured and reasonably powerful attack ship. It is also useful for scouting, as it is the fastest water-based unit. They can see submarines. There are no special exceptions in the specification table. SUBMARINE This is a submersible attack unit. It has the advantage of being difficult to hit, and difficult to spot (by objects that are capable of seeing a submarine). Submarines can only be seen by cities, satellites, destroyers, and of course submarines. There are no special exceptions in the specification table. REPAIR UNIT This is a mobile object that is capable of repairing damage to any object (other than guards). A repair unit cannot repair its own damage - however another repair unit could. The act of repairing is initiated by having the object to repair move to it (click on the repair unit in MOVE MODE). Each time the object is moved to it, one unit of damage is repaired. An object being repaired in this way will lose all remaining movement points in the turn. A repair unit may only repair one object at a time. There is a maximum number of hit points that may be restored by any one repair unit, given by WT. WT also doubles as the actual weight of the repair unit for transport. The repair unit is dismantled when the last of its repair units has been expended. This unit should not be capable of offensive action, so DP, POH, and AR should be set to 0. RAIL CONSTRUCTOR This is a construction unit that places rail segments. It has limited defensive capability. The speed of this object, if moved from rail, is given by SP (LAND). If this object is moved from a location with no rail, all movement points are used (thus it has a speed of 1 when not on rail). This unit has an auto-placement (A-P) mode where a segment is placed automatically each time the object is moved to a new location with no feature object already present. Placement will only occur at the location it is moved TO when this mode is on. There is also a manual placement command that can be used to place a segment at its current location, without using up its movement points. WT is the number of rail segments that is given to the object once produced. It is dismantled when the last of its rail segments is placed. RAIL TRANSPORT This is a rail transportation unit, often referred to as an RT. It may only travel on rail (and can of course move into cities or settlements), and it does not matter who owns the rail. There are two modes of movement that may be set in MOVE MODE that governs the behaviour of the RT with respect to path selection: Minimum Distance Tracking (MDT) can be turned on or off. If MDT is off, the RT will ask you which rail segment to move to at every intersection, in the form of a request to give a direction to avoid an obstacle. An intersection is defined such that the number of rail segments immediately surrounding a given location is greater than or equal to 3. The RT remembers where it came from during movement, so as long as there is only one choice of rail to move to (other than where it came from), it will move there without question. If MDT is enabled, a certain degree of intelligence is applied (well, the best I could do given memory constraints). MDT is automatically turned on when the RT is assigned a schedule (RTS), so that the RT may move from city to city (or wherever) without asking you for directions each time. Theoretically, so long as the rail layout is reasonably uncomplicated, the RT in MDT mode should find its way to its destination. See the section on the MDT algorithm for a more detailed description of its "intelligence". The Rail Transport Schedule (RTS) is a very handy method for the regular transport of resources around a large area. This is described in another section. The RTS is obviously useless if playing in POOLED RESOURCES mode. WT is the total weight that this transport can carry. BOMB Bombs are individual, independent objects, like resource containers. They may only be transported by the STEALTH BOMBER, and of course may only be dropped and detonated from a bomber. They have no offensive capability on their own (you cannot unload a bomb beside a city and then detonate it). Bombs are produced individually as well, by cities, as any other object. Bombs inside a city may not be directly loaded onto a bomber inside the city - they must be loaded as any other object is loaded, by moving into it. In this case, the bomber must be placed just outside the city and have all the bombs load into it from inside the city. If they are just left outside, they are of course very vulnerable to attack. You may regard this unit as being a single bomb, or a group of bombs - it really doesn't matter. The number of bombs that can be loaded onto a bomber is only determined by the weight (WT) of the bomb and the weight capacity (WT) of the bomber. DP is of course the damage potential the bomb can do if dropped on top of the object. SP must be set to 0; FR, SR, POS should be set to 0. GUN BOAT This is a small, lightly-armoured and not-so-powerful boat. It is generally the equivalent of an army except it floats. There are no special exceptions in the specification table. HYDRO-SETTLER UNIT This is a settlement construction unit that can only move on water on its own accord to a location where you wish to build a SETTLEMENT. It was conceived to have limited offensive capability (namely, lots of men with tools). There are no special exceptions in the specification table. CITY DEVASTATOR This is an independent, mobile unit that is used to completely destroy one of your own cities. It cannot be used to devastate a city you do not own! To devastate a city, you must move it inside and give it orders to devastate. All objects inside the city will of course be destroyed as well (if you are silly enough to leave them inside). You will probably only use this if your city is about to be taken over, and there isn't much of a chance of taking it back. Be aware that the Neutral Player is quite capable of building and using these - if you are attacking one of its cities and it suddenly disappears, you'll know why. There are no special exceptions in the specification table. CANAL CONSTRUCTOR This is a construction unit that places canal segments. It has limited defensive capability. WT is the number of canal segments that is given to the object once produced. It is dismantled when the last of its canal segments is placed. 11. TRANSPORT TABLE This table shows which objects can be carried by each transport type. OBJECT TERRA-P AERO-P HYDRO-P RAIL TRANSPORT BOMBER Army X X X X Photon Cannon X X X X Gunship X Mine Layer X X Settler Unit X X X Aero-Fighter X Laser Tank X X X X Fuel Depot X X X X Resource Container X X X X Repair Unit X X X X City Devastator X X X X Bomb X 12. OBJECT SPECIAL-ATTRIBUTE TABLE OBJECT ROAD LOSES FUEL CAN BE HIT CAN BE BONUS OVER WATER BY A MINE BOMBED NP Army X X X X City X Settlement X Photon Cannon X X X Gunship X X Anti-Sat Builder X X X Mine Layer X X X Settler Unit X X X Battle Cruiser X X X Aero-Porter X Aero-Fighter X X Hover-Scout X X Anti-Sat Defense X X Detector Placer X X Laser Tank X X X X Terra-Porter X X X Hydro-Porter X X Road Constructor X X X Fuel Depot X X Stealth Bomber X Resource Container X X Destroyer X X X Submarine X X Repair Unit X X X Rail Constructor X X X Rail Transport X X Bomb X X Gun Boat X X X Hydro-Settler Unit X X City Devastator X X X X Canal Constructor X X X ROAD BONUS This object can be moved to any surface provided that road is built on it. It also has a bonus if moving from the road, such that movement only costs 1 MP. Objects that are non-movement-associated and are capable of existing on all surfaces, do not receive any special treatment moving to or from road (Fuel Depot, Bomb, Resource Container). LOSES FUEL OVER WATER This means that if this object, at the beginning of the turn, is placed in STANDBY or just left with no orders sitting above water, it will lose one fuel unit. If the object happens to run out of fuel at this point, it is immediately killed. CAN BE HIT BY A MINE If this object moves on top of a mine, it is detonated. CAN BE BOMBED This object can be bombed by a stealth bomber. NP Neutral Player cities can produce these objects (assuming they have reached the required tech-level). The NP has an unlimited source of fuel and resources in each of its cities. However, unlike human players that can produce one object for each tech-type at the same time, the NP cannot have concurrent production (in any given city). 13. MAP DISPLAY DESCRIPTION The world is rectangular of size 100 rows and 150 columns. Because of this limitation, distances are not as they may appear. For example, moving from location (0,0) to (2,0) in a vertical direction, i.e. from (0,0) to (1,0) to (2,0) takes the same amount of time and fuel as if moving along diagonals, i.e. from (0,0) to (1,1) to (2,0). In other words, the Pythagorean Theorem is violated! It is important to keep this in mind - you may then find that your movements are in a diagonal nature if your intent is to scan as much area as possible while losing a minimum amount of fuel. A player map display is a rectangular grid, with each location unit occupying two text columns. The row location numbers are listed to the left of the map, and the column location numbers are listed on the bottom, where the first, leftmost digit of the column number is aligned with the first text column of the corresponding locations (it becomes obvious when you see it). The first text column of any particular location unit will either show the object tactical symbol if an object is present at that location, or the surface type icon. The second text column (to the immediate right of the first) shows the object stat if an object is there, the surface type icon again if nothing is there, or a feature object symbol. Feature objects are described in another section. An object stat is a statistical number related to the object. If you own this object, its meaning depends on the object type and the chosen statistic to display for that object type: If the object is a city, it will either display the smallest of the number of turns before an object in the city is produced, or the number of guards in the city; otherwise, it will either display the number of hits the object has left, or the amount of fuel it has left. The buttons for choosing which information to display can be found in TACTICAL MODE (the information type displayed is shown by a check mark). If you do not own this object (it belongs to the enemy), the number displayed is always the age stat of the object. The age stat is the number of turns since you last scanned that particular object - an age stat of 0 indicates that it is definitely at the location shown because you just saw it there. The object stat, if greater than 9, will always be a '+' sign. Since there is no room to display a two-digit number, this character is used to tell you that the object stat is 10 or above. In the case of an enemy object, the age stat is recorded up to a value of 63 - clicking on the object in TACTICAL MODE will tell you the actual age stat value, or will indicate if it is above 63 (you will have the option of removing this object from your map entirely, if you believe that it will most likely not be there anymore - regardless of the actual age stat value so long as it isn't 0). 14. MAP FEATURE OBJECTS This is a category of objects that are for the most part intrinsic to the surroundings. There cannot be more than one of these objects at any one location: For example, it is not possible to build a road on a mineral resource. This restriction is mostly due to display and memory limitations. Note that in MOVE MODE, the feature object symbol is displayed beside the surface type for any given object at its current location. The map feature objects are listed below. GRAIN This is a resource deposit, called grain, but is more generally a food source. For example, a "grain" deposit on water may be considered an area with a high concentration of seafood. The symbol is supposed to look like a wheat field with the letter 'G'. MINERAL This is a resource deposit, called mineral, which is generally an area that can be mined to yield any type of metallic elements for the purposes of construction of objects. The symbol is supposed to look like a pickaxe with the letter 'M'. OIL This is a resource deposit, called oil, but is more generally an area that can be exploited as a fuel source (oil, coal, or natural gas). The symbol is supposed to look like an oil rig (or pump) with the letter 'O'. RAIL Railroad can only be placed by a Rail Constructor. It is only used by Rail Transports (RTs), and will most likely be built to connect cities for the rapid and efficient transport of resources, and other objects. The symbol is a filled circle. ROAD Road can only be built by a Road Constructor (and will appear around neutral player cities wherever the surface is not water or land). It will allow objects to move to a surface that they cannot normally move to. If a surface has road built on it, for movement purposes, the surface will be treated as land. However, all other specifications will be chosen based on the original surface type; these include POH, PBH, POS, PBS, AR, and SR. Therefore, it is important to make sure that specifications for surfaces that the object cannot normally move to are set properly, in the event that they are able to move to that surface because of road (except for objects that are not supposed to exist on land). Obviously, it doesn't make sense to build road on land. The symbol is a hollow square. MINE A mine can only be laid by a Mine Layer. The mine is visible only to its owner, but will detonate if an object of the same owner moves to it. There is no way to disarm a mine - it must be detonated by coming into contact with an object. POH for a mine is 100 and DP is 1 - therefore, the probability of an object initially receiving one damage point is PBH of that object. If a hit is received, the mine gets another attack using the same rules; if it hits again, it will try yet another attack. It is therefore theoretically possible (although not likely) for a mine to sink a Battle Cruiser! If a mine is detonated, the location is clear - a mine can actually be thought of as a mine field where if one mine is detonated, all are detonated simultaneously (by some transmitted signal, or whatever). The symbol is supposed to look like a water mine with the letter 'M'. DETECTOR This can only be placed by a Detector Placer. It is for the most part a passive device that is sensitive to the movement of enemy objects within its scan range. It is generally concealed to the enemy, except that in the event that this device scans an enemy, there is a possibility that the enemy will detect the warning signal transmitted by the detector. If this is the case, the detector has the means to detect an interception of its warning signal, in which case it self-destructs to prevent capture. If you are alerted to the presence of an enemy object within its scan range, the actual location of the enemy is still unknown. The specifications of the detector reside in the game parameter table. Note that the scan range of a detector does not appear in the View scan range mode. The symbol is supposed to look like some sort of scanner with the letter 'D'. CANAL This can only be constructed by a Canal Constructor, on LAND. It is an artificial waterway that will permit water-based objects to move inland. When in the canal, the object's surface specifications will be land-based, not water-based. As a movement penalty, all movement points will be used to move from a canal (however there is no penalty when moving into a canal). It is still possible to move from water into a canal and then back into water in the same turn, depending on the speed of the object. Of course, all other objects that can move on land will be able to transverse a canal (by whatever means: bridges, ferries, etc.) since the primary surface type is still land. The symbol is not easily described - except that it doesn't look like any of the above, so by the process of elimination, it should become apparent (it's some sort of square-like pattern I made up). The following objects can move in a canal: Gun Boats, Hydro- Porters, Hydro-Settler Units, Battle Cruisers, Destroyers, and Submarines. Note that a Settlement cannot be built on a canal. 15. GRAPHICAL WORLD MAP VIEWS A graphical world map view uses the 320x200x256 VGA mode to display various aspects of your world, using colour codes to distinguish between objects. The legend on the right shows the object symbol and its corresponding colour as it appears on the map. The following are the different types of maps that may be obtained through the game options and menus, mostly from the Observation menu: OBJECTS Displays locations of all objects belonging to a particular player that you have scanned, as they appear on your player map. There is no distinction in this view as to the age of the object (how recently you scanned it). KNOWN RESOURCES All resources that you have scanned appear in this view, and are colour coded according to resource type. This view does not indicate collection status of resources - another view is dedicated to this. INFRASTRUCTURE Displays the locations of the following objects: CITY, SETTLEMENT, HQ, RAIL, ROAD, CANAL, MINE, and DETECTOR. COLLECTED RESOURCES Displays the locations of collected and uncollected resources that you have scanned. They are colour coded as such, but resource types cannot be distinguished in this view. HIGHLIGHTING (sometimes abbrev. HILITING) This is a view category, not a specific map view. It is obtained through options such as SURVEYED AREA, VIEW SCAN RANGE, and VIEW ATTACK RANGE. Your objects are shown as BLACK dots, and the highlighting colour codes are essentially the same as the normal surface colours with the intensity increased. Pressing <RB> anywhere will exit the view without changing your player map view location. Pressing <LB> anywhere on the map itself will exit and will move your player map view location so as to be centered about the location you clicked on. LEGEND OPTIONS If you move the mouse pointer on top of any of the legend symbols, the corresponding colour will flash. This may provide more clarity of the positions of any particular object, since some colours may not be easily differentiated. There is always a BMP button at the bottom right of the screen, for any view. This is described further in the next subsection. 15.1 BMP SCREEN CAPTURE This function will copy the entire contents of the screen to a Microsoft Windows 3.0 (or later) device-independent bitmap (DIB) .BMP file, with no RLE compression since for some reason the Paintbrush program is not able to decode RLE (although most of you probably have a better picture viewer than that). It uses roughly the same RGB intensities as the default DAC register settings for that video mode, with some minor adjustments to provide a reasonably good grey shading equivalent for most of us without colour printers. It is therefore a 256- colour bitmap, and appears almost exactly the same as the screen view using whatever picture viewer you have in Windows, so long as you have a 256-colour video driver. It will print nicely from Paintbrush, but since it is only 320x200 remember to adjust the scaling - a 300dpi laser at 100% scaling will give you a nice one- inch or so map! Scaling 500% or so provides a reasonable size at that printer resolution. If your software will support it, choosing Best Fit would work well too. The BMP capture is activated by pointing to it and clicking <LB>. The process is initiated when the symbol lights up and a sound is heard. It is finished when it darkens again and another sound is heard. The filename that it writes to is hard-coded, and must be creatable in the current, default directory. The file size will always be 65,078. The naming convention is as follows: P#T##MMM.BMP, where: P# is the player number, from 1 to 4 (NP); T## is the last two digits of the turn number; MMM is the map type: OBJ - Objects RES - Known Resources INF - Infrastructure COL - Collected Resources HIL - Highlighting view or WORLD.BMP, if it was a world map view from the MAP EDIT function of REXEDIT. These files will be overwritten if the particular map view satisfies the same criteria. For example, a BMP made from viewing SCAN RANGE will be overwritten by another BMP request from viewing ATTACK RANGE. If it is necessary to have these two separate views recorded, you will have to capture one view, save and exit the game to rename the file, and run the game again for the other view. As a note of caution, there is no security mechanism integrated in bitmap files, and so be careful not to leave them accessible to other players, who may be of a less-honourable nature, or just clumsy enough to accidentally view them. So be careful to look for the player number in the filename, and remember what number you are! If you are curious as to the format of the DIB, look in your favourite Windows GDI reference under the following data structure names: BITMAPFILEHEADER, BITMAPINFOHEADER, BITMAPINFO, and RGBQUAD. 16. MOVE MODE Move mode must be entered manually every turn. This mode consists of a number of movement phases, consisting of two cycles. In the first cycle, orders are requested (if needed) for all objects, one at a time; generally speaking, orders are asked for objects that have no orders and have at least one movement point (MP). An order can be movement-related, or it can be an attack order (by just clicking on an enemy object within attack range). Note that once you make an attack on an object, all movement points are used up. In the second cycle, actual movement takes place. It is in the second cycle where collisions may occur (generically speaking) where you are asked to indicate an alternate location to move to to avoid an obstacle. It may be of course that in a movement phase, it may only appear to execute the second cycle, but it does execute the first cycle each phase in the event that an object may clear its own orders for a variety of reasons: it reached its destination; it encountered an enemy object within scanning range; or it is running low on fuel (below a safety margin) in which case the object will have to be guided to wherever it is going each movement phase, which will hopefully prevent accidental destination orders that will cause it to run out of fuel. As long as there is an object that is capable of moving this round, and has orders to move, new movement phases will be executed until that object runs out of movement points. Move mode will then end on its own when it decides that no more movement phases are required. Since it is possible to exit move mode prematurely (by clicking in the designated area), it is wise to make sure you enter move mode again before ending your turn. It is for this reason that a warning may appear before you confirm end of turn that indicates that there is at least one object that is capable of moving (whether or not it has orders). For the most part, you need not be concerned about the actual order of operations that are described above. However, there is one good reason for understanding this, which pertains to loading objects onto transports: If you intend on loading one or more objects onto a transport, and have the loaded transport move in the same round, you will want to be sure that the objects have indeed loaded themselves on first. If not, the transport will move and then the object to be loaded may either move to the prior location of the transport, or it may not be able to move at all. You will then have wasted precious time, having to move your transport back to where it was. In order to prevent this, there are two procedures that are recommended: 1. Assuming the transport has its orders cleared and is capable of moving this round, first give the loading orders to the appropriate objects, and when the transport asks for orders, click on "Other Orders" (the area to click in is designated in move mode) and examine the current payload of the transport: If these objects to load are not there yet, exit this window and press <RB> to temporarily skip this object and wait until the next time the transport asks for orders, at which point the objects should be loaded; otherwise if they are there, you may now give movement orders, confident that you are not leaving your cargo behind! 2. If not already, put the transport in STANDBY (or WAIT) mode, and then give the appropriate loading orders. Wait until move mode finishes, enter Tactical mode, click on the transport, and clear its orders. You may then enter move mode again to move your transport. This will ensure that sometime during move mode, the objects to load will have moved onto the transport. The risk of doing it this way is that you may forget about the transport altogether - once it is in STANDBY, it won't come out of it until something nasty happens at which point it could be disastrous! Note that pressing the <RB> when an object asks for orders will only skip it until the next movement phase, if any! Since move mode ends when nothing happens in the second cycle (during movement), it is possible that by continually skipping this object every phase, move mode will end and you may forget about it. This is the primary reason for the warning message described earlier that may appear when choosing to end the turn. It is handy to skip giving orders to an object in the event that another of your objects is in the way - the obstructing object will then hopefully move in the second cycle of this phase, and you will be able to give your object movement orders next phase. In any event, skipping an object will not under any circumstances inhibit its abilities this round. However, you may not carry over its movement points into the next round! An exception to this is in a different situation, where an object that already has movement orders does not have enough movement points to move from where it is, in which case its remaining movement points ARE carried over into the next round (quite transparently). An example of this is if a Laser Tank with 1 MP inside a Jungle (where 2 MPs are required to move from it) wants to move somewhere, it won't move this round, but it will carry over the 1 MP to the next round. It will then have 3 MPs (more than usual), but will move right away and use up 2 MPs doing it, leaving it with 1 MP again. You may notice that for each type of object, a particular set of options appear in the status window (top-right corner) when in MOVE MODE. These options are identified by their first letter being boxed in. An example is the [S]tandby order, which appears for every object. These options may be selected with the mouse pointer by clicking in these small boxes, or may be accessed directly via the keyboard whereby pressing the key corresponding to that boxed in will activate that option. Note that CAPS LOCK should be OFF, as these keyboard commands will only accept lower-case input. That is, 's' is for Standby, but 'S' won't do anything. The following are extra keyboard options that are not shown in the status window: [c] - Position the main map so that the object in question is centered (helpful if you wandered off somewhere using the scroll bar and don't know your way back!), [w] - Give orders to WAIT. Note that this order may also be given by selecting the Other Options field at the top to open the object's window where the WAIT option is available. 17. RAIL TRANSPORT (SCHEDULES AND MDT) 17.1 RT SCHEDULE (RTS) An RT Schedule is a means of automatically shipping resources on a regular schedule to various cities. Once your empire is large enough, this system can save a lot of playing time and frustration if the schedule is set up properly - resources that cities need can be delivered to them on a regular basis so that production can hopefully proceed without long delays (while waiting for resources it doesn't collect). There is a maximum of 15 schedules, and 16 order entries per schedule. Note that an implied entry exists (but does not appear) at the very end of the orders list which instructs the RT to loop back to the top of the list to retrieve its next order. The time it takes for the RT to complete one loop in the order entry list is called the Round Trip Time (RTT) and is displayed at the top when examining this list. To activate a schedule, you must ASSIGN a particular RT to the schedule, at which point it will begin at the current order entry. Assigning an RT will enable its MDT; note however that MDT is off when the RT is produced, which you may want to turn on if you plan on navigating an RT on a regular basis but without using an RTS. The following are schedule order entry options: MOVE TO CITY/SETTLEMENT This order will direct the RT to move to the specified city/settlement. In this order entry, you may give loading and unloading orders for each type of resource. All operations are done when the RT moves into the city/settlement. It will then spend the rest of the turn inside, and proceed to the next order entry next turn. You may also tell the RT to load a priority object and deliver it to another city/settlement. A priority object is one that will be loaded first, before resources are loaded, to be delivered to a destination; if there still isn't room on the RT, resources at random will be unloaded at the city until there is enough room for it. This is a temporary order and will clear itself once the item is delivered. Note however, that unless you specify otherwise, the schedule will still be followed according to the entries listed even before the priority item has been dropped off. MOVE TO LOCATION This is an order to move to an absolute location, which is supposed to be at an empty area - in other words, the RT must somehow be able to get to the specified location without having an object sitting there. This order is only practical for adding an exception to the MDT algorithm if the RT does not follow the appropriate railroad tracks, and/or if you want the RT to wait at this particular location, possibly to allow another RT to pass by. WAIT This is an order to wait a specified number of turns at the current location. This delay may be necessary for a proper time balance in the delivery schedule. The current order entry is pointed to by an arrow in the entry display window, and may be changed manually if necessary. For example, if the arrow points to an entry that corresponds to a city (which may or may not have loading/unloading orders), it indicates that the RT has orders to proceed to this city. However, if you decide that a priority item needs to be delivered to another city later in the orders list in a hurry, you can bypass all orders in-between by manually changing the orders pointer to point to this destination. The schedule will then resume normally after the priority item has been delivered. It is important that you read the on-line help for the orders entry list window when you get there, to be informed of all the options that are available to you. 17.2 MINIMUM DISTANCE TRACKING (MDT) ALGORITHM This is an algorithm that can be used to guide an RT along the network of railroad tracks to a particular destination. A term that needs to be defined is a 'lonely track', which is a railroad path from the source to the destination with no other rail segments branching from it (other than the immediately surrounding areas of the source and destination which are probably rail intersections). Another term to be defined is 'distance', which is the MAX(separation in rows, separation in columns). The 'perpendicular distance' is the MIN(separation in rows, separation in columns). Find a lonely track with the first rail segment at a minimum distance to the destination. If one is found, proceed to the first rail segment of the lonely track. If no lonely tracks are found: Find a rail segment of minimum distance to the destination. If there are at least two: From the last two found, choose the one with closer perpendicular distance. Else if there is just one, proceed to that rail segment. If there is a problem at an intersection with deciding which rail segment to proceed to (it chooses the wrong path), try placing an extra rail segment at the location that is closest to the destination (if it makes sense in your particular context). This algorithm is only applied when an intersection is reached, defined to be an area such that there are more than 2 rail segments immediately surrounding a given location. Once the RT has chosen a path along a lonely 'section' of track (where there are only two options of movement), it will proceed in the same direction, as it will not move to a rail segment that it just came from. However, once the RT reaches its destination, this information is cleared. If an object is obstructing the path of an RT, the algorithm will be implemented the same way except that the segment of rail that the obstructing object is on will be ignored. If this occurs in an area where there is no intersection, the algorithm will conclude that the track ends here and will ask what to do about the obstacle in the way. If this occurs at an intersection (where it will have an alternate rail segment to move to other than where it came) it will always move there, whether or not that segment will eventually lead to the desired destination (although it will choose the best one to move to if there is more than one choice). This is not really a good thing, but in other situations it will allow the RT to pass objects on the rail if the rail is doubled along a path. If this problem persists (at intersections), you may want to place some more rail segments in the intersection - it will then likely choose the segment in the right direction to move around the object. It may get confusing if you have many RT's sharing the same track - but this is not a railroad network simulator that will solve all your traffic problems! Railroad in most cases will be a convenience if not abused; otherwise it could become detrimental. It is a good idea to make sure that rail layout for linking cities makes sense (with respect to this algorithm). A railroad linking a city to the south-west should have its first segment to the immediate south-west of the source city (or at least make sure that all other rail segments are at a larger distance from the destination than the segment meant for the destination). If this logic is applied to all rail layouts, the MDT should not make any errors. If it does make an error however, it may be wise to use the MOVE TO LOCATION option of the rail schedule (if using one) to point it in the right direction. Note that you are able to attack your own rail - you may need to in the event of "restructuring" your network. 18. GAME PARAMETER TABLE The parameters in this table have effect over all current games. They are stored in the file <GAMEPARM.REX>. If this is not in the default directory when the game editor is run, it is created with default settings. A '[D]' before the parameter name indicates that it only has effect when creating new games. A '[P]' before the name indicates that it only has effect when playing a game. GAME PLAYER PARAMETERS - [P]: TURNS TO ADVANCE TO TECH-LEVEL x (x ranges from 2 to 5). This is the number of turns a player needs to wait before being able to advance to the next tech-level of a particular tech-type. PROBABILITY OF RESOURCE BEING SPOTTED This is the absolute probability that a Hover-Scout will spot a resource deposit during scanning. POS of the Hover-Scout plays no role in this case. PROBABILITY OF RAIL/ROAD BEING HIT This is the PBH equivalent for rail and road segments. The absolute probability of an object hitting rail/road is the product of POH (object) and this parameter value. Attacking rail/road is done in MOVE MODE by using the 'A'R button. DETECTION RANGE OF DETECTOR This is the SR equivalent for a detector. PROBABILITY OF DETECTING ENEMY OBJECT This is the POS equivalent for a detector. The absolute probability is the product of the object's PBS and this POS. PROBABILITY OF DETECTOR BEING SPOTTED This is the PBS equivalent for a detector. The product of this PBS and an enemy object's POS is the probability that if the detector has detected the presence of the enemy object, that the object will intercept the warning transmission, and thus result in the self-destruction of the detector. INCREMENT IN MAX. GUARDS/TECH-LEVEL The number of guards a city can sustain is the base number plus (this value * (highest tech-level of city - 1)). The base number is HI of the city - see City description. MEGACREDIT REVENUE PER TECH-LEVEL You collect a tax from your population according to the total number of tech-levels of all your cities. The tax revenue is the product of this total number of tech-levels and this parameter value. Since the most primitive city has a total of 3 tech- levels (1 for each type), the minimum revenue per turn is 3 * number_of_cities * this_parameter_value. NUMBER OF RESOURCE PACKS IN DEMAND FOR 1 MC INCREASE (Global Market) A resource pack is a group of 5 resource units of the same type. There is a maximum of 50 packs of market inventory for each type. The value of a pack is 1 + (50 - number of packs in inventory currently) / (this parameter value). The amount of MC you will receive for selling a pack is the value as computed above. The cost to buy a pack from the market is this value plus a commission - described next. PERCENT COMMISSION FOR SELLING (Global Market) To buy a resource pack from the market, you must go through a broker who charges a handling fee. The extra amount of commission to pay is (value as computed above * this parameter / 100). Commission can be turned off by of course setting this parameter to 0. MAX WAIT (TURNS) FOR NP TO PLAY (Global Market) The Neutral Player will choose a random time in turns between 1 and this value to play the market (arbitrarily but restricted by parameters below). A new time will then be decided on once a transaction is done. MAX NUMBER OF PACKS FOR NP TO BUY/SELL (Global Market) The Neutral Player will randomly choose a resource type to buy from or sell to. The number of packs for this transaction is restricted by this parameter value. PROBABILITY OF NP REACTING TO BUY/SELL (Global Market) If in the last turn at least one transaction was performed on the market, this is the probability that the NP will react with a transaction of its own. MAX NUMBER OF PACKS FOR NP TO BUY/SELL (Global Market - Reaction) This has the same meaning as the one above except that it only relates to the NP reacting to a transaction. COST TO ADVANCE TO TECH-LEVEL x (x ranges from 2 to 5). This is the cost in MC to attempt to advance a tech-level. If the attempt failed, the funds are still lost, and will have to re-invest the same amount to attempt again. PROBABILITY OF SUCCESSFULLY ADVANCING (tech-level) This is the probability (for all tech-levels and tech-types) that you will successfully advance a tech-level if attempted by investing the funds above. PROBABILITY OF NP ADVANCING A TECH-LEVEL This is the probability that the NP will successfully advance a tech-level. An attempt is made as soon as the required number of turns for advancement has passed. If the advancement failed, the NP will choose a random time between 1 and TURNS TO WAIT FOR ADVANCEMENT to wait before attempting to advance again. The NP may advance tech-types independently and concurrently as a regular player can. PROBABILITY OF NP SENDING MESSAGES This is the probability that the NP will decide to select a message at random from the appropriate file to send to a player. These messages are strictly sent in reaction to an attack, either by or on the NP. See the section on PLAYER MESSAGES. PROBABILITY OF CANAL BEING HIT This is the PBH equivalent for canal segments. The absolute probability of an object hitting a canal is the product of POH (object) and this parameter value. Attacking canals is done in MOVE MODE by using the 'A'R button. PROBABILITY OF NP SENDING PATROLS This is the probability that the NP will send a Hover-Scout on patrol, if it has nothing else to do. This decision is evaluated every turn for every inactive Hover-Scout. The higher this parameter is, the more likely you will be discovered by the NP early in the game. PROBABILITY OF NP MINING IF ON WATER This is the probability that if a Mine Layer happens to be on water, it will lay its mine right there, even if it originally had orders to lay it somewhere else. This decision is evaluated each time it moves to water. If this parameter is set high, it is more likely that the coast line will be mined as opposed to other surfaces. It will also be more likely that mines will be laid very close to island cities (see below). MINIMUM DISTANCE FROM HOME TO MINE WATER The above test for laying a mine on water will only take place if the distance of the Mine Layer from its home is at least the distance specified here. This parameter is important for island cities in that it will hopefully prevent the city from mining itself into a closet! For this reason, it is a good idea to set this value to be at least 3, so that exceptions for mine laying on water won't take place until the Mine Layer is at a reasonable distance away from its city. This has no influence on the original decision on where to mine - only on the exception explained above. (1P) MINIMUM NP MARKET REACTION For a one-player practice game, this provides an additional form of market transaction damping. This is the minimum number of resource packs the NP will buy or sell in immediate response to a transaction, so long as at least this number were sold or bought, respectively. If the transaction for a particular resource type involved fewer packs, no minimum reaction will occur. However, the NP will always react by a random amount as described next. (1P) PROBABILITY OF FURTHER REACTION Related to the above, this provides another addition form of reaction on top of the minimum, if any. An additional resource pack will be bought or sold (corresponding to sold or bought by the player) each time the probability test succeeds. It will cease to react further the first time it encounters a failure. Therefore, DO NOT set this probability parameter to 100!!! GAME EDITOR PARAMETERS - [D]: NUMBER OF EACH RESOURCE This is the minimum number of resources of each type that will be placed on the map. If building a game without regions, four extra resources will be placed around each HQ. Therefore, in a 2- player game, the total number of resource deposits (of all types) will be 3 * this_value + 2 * 4. NUMBER OF IN-LAND CITIES This is the number of Neutral Player (NP) cities that will be placed in-land. In-land is defined to be a location where the 8 immediately adjacent (surrounding) surfaces are anything but water. NUMBER OF COASTAL CITIES This is the number of NP cities that will be placed in coastal areas. Coastal is defined to be a location where at least one of the 8 immediately adjacent (surrounding) surfaces is water. NUMBER OF ISLAND CITIES This is the number of NP cities that will be placed on an island. An island is defined to be a location where all of the 8 immediately adjacent (surrounding) surfaces are water. CITY SPREAD FACTOR/CITY DISTANCE FACTOR The way that cities are placed on the map can be further customized using these parameters to govern inter-city distances. The placement algorithm is such that if a location for a city is chosen to be within a distance of CITY DISTANCE FACTOR of another (already established) city, that the city will NOT be placed there given a probability of CITY SPREAD FACTOR. Therefore, to spread cities further apart from each other, you would want to raise CITY SPREAD FACTOR and drop CITY DISTANCE FACTOR. Obtaining a good balance is difficult for giving the desired distribution of cities, so experimentation of these parameters should be done first before building a game for playing. Experimentation should be done as follows: Set the values accordingly; Clear the current world map; Load a new world map; Build a new game using Regions; Once built you will be placed in the editor - select the Neutral Player; Select the Objects option to display a graphical world map to observe the locations of the cities; and Repeat if necessary. PROBABILITY OF x RESOURCES AROUND CITY (x ranges from 1 to 5). All 5 of these parameter values MUST add to 100! The results otherwise will be strange at best. When a city is placed, these probabilities will be used to decide how many resource deposits (of completely random type) will be placed within collection range of the city. It is important that the parameter NUMBER OF EACH RESOURCE is set high enough to accommodate the number of cities that will be placed. Otherwise, some cities may find that they have no resources in collection range! If after all cities have been placed, there are resources still left to place according to the parameter just mentioned, then they will be distributed randomly over the world. It is therefore possible for a city to have more than 5 resources in collection range. Also notice that the way the probabilities are set in this group of parameters will determine the degree of clustering of resources about cities. If it is set such that it is most probable that only 2 resources will be placed with a city, there will be more resources left over after city placement to be distributed uniformly over the world. Using the opposite parameter settings will force resources to cluster around cities, which may place more of an importance to cities for resource collection purposes and less of an importance to settlements, for collection away from cities. MAX AGE (10's OF TURNS) OF N-CITY The age of a city when placed is randomly chosen up to this maximum. The age will have a direct influence on the level of technology of the city at the start of the game: When the city is placed, a simulated run over the number of turns specified by the age is performed which accounts for tech-level advancement decisions as would normally occur during play. This gives the cities a head-start in production capability. This parameter is closely tied to the probability of NP advancing, and the waiting time to advance a level - it is difficult to obtain a good balance. Note that since parameter values must be byte-sized (may only go up to 255), this parameter is entered in 10's so that theoretically the maximum age will be 2550 turns - which would definitely ensure very well-developed NP cities! Note that production does not take place during this simulated run - only tech-level advancement. 19. PLAYER MESSAGES Players may send one-line messages to each other, that will appear at the very beginning of each round. Sending messages to the Neutral Player will have no effect, unless you want to write yourself a memo (if you remember to check it). Depending on the probability set in the Game Parameter Table, the Neutral Player may decide to send a particular player a message. These messages are taken randomly from either <WINNING.REX>, if the NP attacks this player; or from <LOSING.REX>, if the NP is attacked by this player (which has precedence over the former). You may freely add messages to these text files, so long as they are no longer than 78 characters long. Only the first 255 messages in each file will be considered - the rest will be ignored. Also, be sure that there are no blank lines, especially at the very end of the files. 20. TECHNICAL INFORMATION Most of the source code was written in C and compiled using Borland C++ 3.1; the rest of the source was written in assembler for lower- level operations and was assembled using Turbo Assembler 3.1. The total size of all code segments in the Game Player is about 120,000 bytes; the rest is data. The total size of all code segments in the Game Editor is about 60,000 bytes; the rest is data. The code size described here does not include the startup code or any other Borland library code that is linked in from the standard library, which adds an overhead of about 16000 bytes. It is a good idea to use a file compression utility to archive non- current games (or to back up a current game) as by nature these games files are very predictable in content (the same bytes recur for a long time). 20.1 WORLD MAP SAVE FORMAT I thought it would be a good idea to describe the format in which world maps are saved. This would be useful to anyone who would like to write a program to generate world maps, if they happen to know or make up a good algorithm. I haven't put much thought into a method for randomly generated maps with all feature types - mainly because I don't have time. I have a reasonably good algorithm for generating only land/water maps, but is not completely developed. If anyone happens to write a good map generator, I would be pleased to know about it. Each location corresponds to one byte in the map file. The map is stored in a sequence from the top left to the bottom right as in this for-next loop: FOR i = 0 to 99 DO FOR j = 0 to 149 DO WRITE MAP BYTE FOR LOCATION (i, j) END DO END DO (i is the row number and j is the column number, ranging from (0,0) to (99,149)). The file size must therefore be exactly 15,000 bytes. The map byte is defined as: X7 X6 X5 X4 X3 S2 S1 S0 (in order of MSB to LSB). The X's are used for storing information other than surface type, and must be initialized to all 0's when creating a new map. The following is a table of surface types: SURFACE TYPE S2 S1 S0 Land 0 0 0 Water 0 0 1 Mountains 0 1 0 Swamp 0 1 1 Jungle 1 0 0 As can be seen, there is room for 3 more surface types. However, do not invent another one - these surface types are hard-coded. Let's just say that 101, 110, and 111 are reserved for the future. So it's really just a matter of writing either a 0, 1, 2, 3, or 4 as a byte value for each location. You may even choose to write a program to print out a map based on this information, if the current BMP method is unsuitable. It would be far too complicated to try to explain how player map information is stored - it took a long time to develop, including several revisions of my data structure to accommodate new features, etc. 21. FUTURE POSSIBILITIES / CLOSING COMMENTS If there is enough interest, I may consider adding some more features to this game (provided I have the time). Some of which may be the following: - Make the world wrapping in the east-west sense. - Add spying/intelligence: able to obtain random information about the enemy, or promote insurgence; costs MegaCredits to support spies and counter-intelligence (currently half-developed). - Make the NP more intelligent (or change certain aspects of its behaviour) - depends on specific reactions from people. - Allow the NP to produce bombers and perform bombing runs. This may make practice games more interesting once the immediately surrounding cities are taken. - Add natural disasters. - Add more object types. - Add real-time modem/network support (maybe in another lifetime). - ... or any other suggestions. The truth is, I never originally intended on this game to get so complicated: I am therefore running out of conventional memory! I may be able to add a few things, but cannot do anything drastic. Someone may comment that the user interface isn't really up-to-par with the latest releases of software - this is primarily because six years ago the approach seemed like a good idea at the time. As I haven't envisioned releasing this publicly, I wasn't very concerned about a having a well-thought-out and consistent interface - I just took scraps of code here and there and what you see is what you got. I apologize for this (in some sense) but to be blunt, this is what you get for free (I've wasted enough of my life already). By the way, I couldn't see myself charging anyone for this, so I decided not to release it Shareware - I figured it would only aggravate people if I started building in restrictions in the code (such as abruptly stopping the game at turn 100) to persuade people to register and send money. In any case, I hope someone out there enjoys this game! ------------------------------------------------------------------- Borland C++ and Turbo Assembler are trademarks of Borland International, Inc. Microsoft Windows is a registered trademark of Microsoft Corporation. <END OF DOCUMENT REX.DOC>